Solid 2.0 support across the toolchain, 0.2.0 - #5

Recorded on the branch rather than in a private note, because the number
that matters contradicts the assumption: this was scoped as "three packages
need Solid 2 support" and the whole dependence is 32 sites in one 437-line
file, plus two lines of Rust. The rsbuild plugin has none at all.

The one genuinely hard piece is the four-bucket splitProps that routes every
prop through the runtime; omit() returns only a remainder, so the bucket
boundaries have to be re-derived rather than falling out of the call.

The runtime used four things Solid 2.0 changed, and three of them can be
told apart at runtime from the module object itself: `splitProps` became
`omit` and lost its subset half, `Context.Provider` became the context,
and `useContext` now throws where it used to return `undefined`. Those
are handled in place - detected once at load, or spelled so both majors
read it the same way, which is why `createContext<UIConfig>({})` now
carries a default it never needed before.

The fourth cannot. 1.9 serves `Dynamic` and `createComponent` from
`solid-js/web`; 2.0 moved them to `@solidjs/web` and dropped the old
subpath, so no single import statement resolves under both. That one
module is now `renderer.ts`, and the build emits the tree twice with its
2.0 twin swapped in. `dist/component.js` and `dist/solid-2/component.js`
are identical files; the renderer is the whole difference.

The prop routing is the part that changed shape rather than name. One
`splitProps` call returned all four buckets and made them disjoint by
construction. `omit` returns only the remainder, so the three routed
buckets are picked by name and the bucket each declared key belongs to is
decided once per component instead of falling out of the call.

145 tests pass under 1.9, unchanged. The 2.0 output is emitted and its
declarations bind to `@solidjs/web`, but `skipLibCheck` means it has not
been checked against an installed solid-js 2 yet.

The runtime ships twice because Solid 2.0 moved `Dynamic` and
`createComponent` out of `solid-js/web` and dropped that subpath. A
generated component has to import its boundary from the matching entry,
and the compiler is what writes that import, so it needs to be told which
major the build targets: `solid: 2` emits
`solid-layouts/solid-2/application-boundary` in place of
`solid-layouts/application-boundary`.

Told rather than sniffed. The compiler sees one source file, and which
Solid an application runs on is not written in it.

Default is 1 and the emission is byte-identical to before, which the test
asserts directly rather than by inspection: a host that has never heard
of this option keeps getting what it always got.

The builtins list gains 2.0's renames - Suspense to Loading, SuspenseList
to Reveal, ErrorBoundary to Errored, plus Repeat - and the source check
admits `@solidjs/web`. Neither is gated behind the option, because the
check tests a name against a module and no 1.9 build can import `Loading`
from a Solid module that does not export one.

60 Rust tests and 21 JS tests pass. Verified through the rebuilt binding,
not only through the Rust: all three of unset, 1 and 2 emit what they
should.

`pluginSolid2LayoutsLibrary` and `pluginSolid2LayoutsApplication`, beside
the existing pair rather than in place of it. They thread `solid: 2`
through to the compiler, so the library emits its boundary import against
`solid-layouts/solid-2/application-boundary` and the application aliases
that specifier to the runtime's `./solid-2` entry instead of its root.

Separate names rather than an option on the old ones, because the choice
is not independent of the rest of the build: it has to agree with
`pluginSolid2()` and with the installed `solid-js`. A name that must match
its neighbour in the plugin list is easier to get right, and to read back
later, than a flag that must:

    pluginSolid2LayoutsLibrary(),
    pluginBabel({ include: /\.(?:jsx|tsx)$/ }),
    pluginSolid2(),

Asking a runtime that predates this for `./solid-2` now says so by name
rather than quietly falling back to `main` and serving the wrong major.

Both modes verified against the real compiler, not only the plumbing:
bundle mode through a new test in library.test.js, and source mode - the
one @pathscale/ui uses - by generating a fixture both ways and reading the
header. Unset and 2 differ in exactly that one specifier and nowhere else.

Minor rather than major, and not a prerelease: 1.9 is still the default
on every entry point, `pluginSolidLayoutsLibrary` and its application twin
are untouched, and the compiler emits byte-identical output when `solid`
is unset. Nothing that installs 0.1.x breaks on 0.2.0.

All three move together because the feature spans all three: the runtime
gained a second build, the compiler gained the option that picks it, and
the plugin gained the pair of names that sets the option.

`index.js` regenerated - napi bakes the package version into the binding
loader's mismatch check, so a bump that skips it publishes a loader that
rejects its own binary.